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REMARKS 

Claims 1-39 are pending in the application. 
Previous Rejections 

Withdrawal of the previous rejections is noted and appreciated by the Applicant. 

35 U.S.C. $ 102 and $ 103 Rejections 

In the present Office Action, claims 1-7, 9-12, 13-19, 21-36, and 38-39 stand 
rejected under 35 U.S.C. § 102(e) as being anticipated by newly cited U.S. Patent No. 
6,195,680 (hereinafter "Goldszmidt"). Further, claims 8, 20, and 37 stand rejected under 
35 U.S.C. § 103(a) as being unpatentable over Goldszmidt in view of U.S. Patent No. 
6,249,801 (hereinafter Zisapel). Applicant respectfully traverses the above rejections and 
requests reconsideration in view of the following discussion. 

Generally speaking, the examiner seeks to equate Goldszmidt' s system of a client 
receiving a stream from one of multiple servers with the presently claimed features of a 
multi-streaming microprocessor and processor core. However, the nature of Goldszmidt's 
system is quite different from that of the presently claimed invention, and the features of 
the presently claimed invention are readily distinguished from the cited art. For example, 
in Goldszmidt it is stated that: 

"[t]his invention relates generally to providing fault tolerance and load 
balancing for real-time data streaming. More particularly, it relates to a 
client-based dynamic server switching method for use in a distributed 
system including multiple servers that are simultaneously 
transmitting one or more real-time multimedia streams." (Goldszmidt, 
col. 1, lines 6-12, emphasis added). 

Further, Goldszmidt discloses: 
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"The client agent 1.8 (also called simply client) can be any conventional 
computer or processor-based machine with a processor, memory and 
operating system and application software and networking (hardware and 
software) to communicate requests and receive data streams from a 
streaming server." (Goldszmidt, col. 5, lines 26-31). 

It is therefore apparent that Goldszmidt' s client includes the components of a 
stand-alone computer system or machine that is configured to receive data streams from a 
one of multiple servers that are separate from, but connected via a network to, the client. 
In contrast, Applicant's presently claimed invention is generally directed to a 
microprocessor and processor core, and methods therein. For example, Applicant 
describes: 

"One of the challenges to processing data packets at high speeds is to be 
able to implement functional resources within a processing core using less 
real estate (silicon/circuitry) than is typically used. Another challenge, at 
least in multi-streaming processors, is how to optimize (speed up) parallel 
processing of multiple data packets from separate packet flows while 
sharing resources in a processing core." (Description, page 4, lines 11-16). 

Applicant believes distinctions between the claimed invention and the cited art 
are clear from both the language of the claims and the specification. Given such a stark 
contrast between the nature of the presently claimed invention and the cited art, Applicant 
submits equating the various elements of the claimed invention with elements in 
Goldszmidt as is done in the present Office Action is untenable. For example, claim 1 
recites, in part, "A context-selection mechanism for selecting a context from a pool of 
contexts for processing a data packet comprising: an interface for communicating with a 
multi-streaming processor, said multi-streaming processor hosting the pool of contexts " 
and "functional units housed within the multi-streaming processor." As discussed further 
below, the cited art does not disclose the features as recited. 

Claim 1, reproduced below for reference purposes, recites: 



9/15 



Application Serial No. 09/881,628 - Filed June 13, 2001 



"A context-selection mechanism for selecting a context from a pool of 
contexts for processing a data packet comprising: 

an interface for communicating with a multi-streaming processor, 
said multi-streaming processor hosting the pool of contexts; 

circuitry for computing input data into a value according to one or 
more logic rules and for selecting a context from the pool 
of contexts based at least in part on the value; and 

a loading mechanism for preloading the packet information into 
the selected context for subsequent processing; 

characterized in that the computation of the input data functions to 
enable identification and selection of a context for 
processing a data packet according to the logic rule at the 
instant time such that a multitude of context selections 
made over a period of time facilitate balancing of load 
pressure on functional units housed within the multi- 
streaming processor and required for packet processing." 

It is noted that the multi-streaming processor hosts a pool of contexts and houses 
functional units required for packet processing. In the Office Action, Goldszmidt is cited 
as disclosing all of the features of claim 1 . In particular, on page 3 of the present Office 
Action, the examiner states that Goldszmidt discloses: 



"an interface (client agent, Fig. la) for communicating with a multi- 
streaming processor (for communicating with server architecture, see 
elements 1.7, 1.8, Fig. la)." 

However, Applicant does not find disclosure in Goldszmidt of a "multi-streaming 
processor," as recited. On page 3 of the Office Action the Examiner equates the server 
architecture of Goldszmidt with the recited multi-streaming processor and a streaming 
server with a context, and on page 4 of the Office Action the examiner equates a 
streaming server with the recited functional unit. In particular, Goldszmidt teaches "the 
server architecture includes a control server 1.1 and at least two sets (1.5, 1.6) (also called 
clusters) of streaming servers (1.2, 1.3)" (Goldszmidt, col. 4, lines 29-31). However, 
Applicant submits Goldszmidt' s streaming servers are clearly not equivalent to the 
recited contexts hosted by a processor and functional units housed within a processor. 
Rather, Goldszmidt discloses: 
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"Streaming technology can be used to deliver live audio and video data, 
where the clips arrive in streams so that users can begin to view or hear 
the clip before the download is complete. Conventional Internet traffic is 
short-lived, with a duration ranging from milliseconds to seconds, and 
bursty. In contrast, real-time multimedia streaming is lengthy, with a 
duration ranging from minutes to even hours, with low continuous 
bandwidth requirements. Server and/or network failures will terminate the 
real-time streaming process, and the stream from a given server will be 
interrupted for a particular session. This interruption may, in many cases, 
only be detected at the client. Thus, a need exists for a client-based means 
to automatically switch to an alternate server in order to continue 
receiving a multimedia stream in an uninterrupted fashion in the event of a 
service degradation, load imbalance, or failure. The present invention 
addresses such a need." (Goldszmidt, col. 2, lines 19-35). 

As may be seen from the above, Goldszmidt's streaming servers are intended to 
address the need for automatically switching among multimedia streams from multiple 
Internet-connected servers. Therefore, Goldszmidt's streaming servers are distinct, 
Internet connected devices, rather than being functional units of a processor or contexts 
hosted by a processor. Accordingly, Applicant finds no teaching or suggestion in 
Goldszmidt of a "multi-streaming processor hosting the pool of contexts" as is recited in 
claim 1, or of "functional units housed within the multi-streaming processor and required 
for packet processing," as is further recited in claim 1. For at least these reasons, 
Applicant submits that claim 1 is patentably distinguishable from the cited art. Each of 
independent claims 13 and 26 are also distinguishable for similar reasons. As the 
dependent claims include at least the features of the independent claims upon which they 
depend, they are likewise distinguished for at least the above reasons. 



In addition to the above, on page 3 of the present Office Action it is suggested 
that Goldszmidt discloses "a loading mechanism for preloading the packet information 
into the selected context (affinity tables are maintained in the TCP router/control server, 
see col. 6, lines 32-60) for subsequent processing (to maintaining affinity records to 
indicate which node is client was routed to, see col. 6, lines 32-60). However, Applicant 
disagrees. Rather, Goldszmidt discloses: 
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"The affinity-based system includes a multi-node server, wherein any of 
the server nodes can handle a client request, but wherein clients have 
affinity to one or more of the server nodes that are preferred to handle a 
client request. Such affinity is due to state at the servers either due to 
previous routing requests, or data affinity at the server. At the multi-node 
server, a node may be designated as a TCP router. The address of the TCP 
router is given out to clients, and client requests are sent thereto. The TCP 
router selects one of the nodes in the multi-node server to process the 
client request and routes the request to this server; in addition, the TCP 
router maintains affinity tables, containing affinity records, indicating 
which node a client was routed to. In processing the client request, the 
server nodes may determine that another node is better suited to handle the 
client request, and may reset a corresponding TCP router affinity table 
entry. The server nodes may also create, modify or delete affinity records 
in the TCP router affinity table. Subsequent requests from this client are 
routed to server nodes based on any affinity records, possibly combined 
with other information (such as load)." (Goldszmidt, col. 6, lines 40-60). 



As may be seen from the above, Goldszmidt' s affinity tables contain indications 
of server state and/or previous routing decisions, not packet information for subsequent 
processing. Also, even were one to assume, arguendo, that Goldszmidt's streaming 
server is equivalent to a context as recited, Applicant notes that Goldszmidt's affinity 
tables are not maintained in a streaming server, but rather in the TCP router/control 
server. Accordingly, Applicant finds no teaching or suggestion in Goldszmidt of "a 
loading mechanism for preloading the packet information into the selected context for 
subsequent processing," as is recited in claim 1. For at least these reasons, Applicant 
submits that claim 1 is patentably distinguishable from the cited art. Independent claim 
13 is also distinguishable for similar reasons. 



In addition to the above, the dependent claims recite additional features not 
disclosed or suggested by the cited art. Some examples of such features are provided in 
the following discussion. For example, each of claims 7, 19, and 22 recite features 
regarding inputting statistical data into computation circuitry about previous processing 
time periods required to process similar data packets. It is suggested that Goldszmidt 
discloses these features at col. 10, lines 49-63. However, the cited disclosure of 
Goldszmidt merely states that a client could determine a server's delivery rate by 
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comparing a server's time stamp with the delivery time of a packet. Applicant submits 
the ability of a client to calculate a time difference is not equivalent to inputting statistical 
data about previous processing time periods required to process similar data packets. 
Also, each of claims 10 and 22 recites features regarding inputting data from a third party 
into computation circuitry. There is nothing in Goldszmidt that suggests these features. 
Accordingly, Applicant submits that claims 7, 10, 19, and 22 are patentably 
distinguishable from the cited art for at least these additional reasons. 

Further, claims 1 1 and 12 recite a distribution of functional units that is symmetric 
or asymmetric, respectively. Goldszmidt includes no such teachings. Rather, Goldszmidt 
merely discloses assigning servers using even numbered ports to one set and assigning 
servers using odd numbered ports to another. This assignment says nothing about the 
symmetry or asymmetry of the resulting distribution. For at least these reasons, 
Applicant submits that claims 1 1 and 12 are patentably distinguishable from the cited art. 
Further, as claims 23 and 29 recite limitation similar to those of claim 1 1 and claims 24 
and 30 recite limitations similar to those of claim 12, these claims are believed patentably 
distinguishable from the cited art as well. 

Finally, while each of claims 8, 20, and 37 are patentably distinct for at least the 
reasons given above, Applicant submits the additional features of claims 8, 20, and 37 are 
neither disclosed nor suggested by the cited art. For example, claim 8 recites the 
additional features "wherein the input data into the computation circuitry further includes 
statistical data about the distribution of instruction types associated with individual ones 
of previously processed and similar data packets." In the Office Action it is generally 
suggested that because Zisapel discloses both DNS requests and HTTP requests, it 
somehow would have been obvious to modify Goldszmidt with the teachings of Zisapel 
so that the computation circuitry further includes statistical data about the distribution of 
instruction types associated with individual ones of previously processed and similar data 
packets. Applicant disagrees. It is first noted that the recited instruction types are not 
equivalent to the disclosed DNS and/or HTTP requests. Rather, this distinction between 
instruction types and DNS or HTTP requests simply further highlights the distinctions 
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between the nature of the claimed invention and that of the cited art. As discussed above, 
the claimed invention is generally directed to a processor and instructions therein. The 
computing system of Zisapel with its disclosed requests bears no resemblance to the 
presently claimed invention. Accordingly, Zisapel does not disclose the recited 
instruction types and the combination of Goldszmidt and Zisapel does not provide all the 
features of the claimed invention. Therefore, Applicant submits a prima facie case of 
obviousness has not been established with respect to these claims. 
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CONCLUSION 

Applicant submits the application is in condition for allowance, and an early 
notice to that effect is requested. 



Respectfully submitted, 
/James W. Huffman/ 
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